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Content Distribution Network Interconnection (CDNI) Requirements 
Abstract 


Content delivery is frequently provided by specifically architected 
and provisioned Content Delivery Networks (CDNs). As a result of 
significant growth in content delivered over IP networks, existing 
CDN providers are scaling up their infrastructure. Many Network 
Service Providers (NSPs) and Enterprise Service Providers (ESPs) are 


also deploying their own CDNs. To deliver contents from the Content 
Service Provider (CSP) to end users, the contents may traverse across 
multiple CDNs. This creates a need for interconnecting (previously) 


standalone CDNs so that they can collectively act as a single 
delivery platform from the CSP to the end users. 


The goal of the present document is to outline the requirements for 
the solution and interfaces to be specified by the CDNI working 
group. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7337. 
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1. Introduction 


The volume of video and multimedia content delivered over the 
Internet is rapidly increasing and expected to continue doing so in 
the future. In the face of this growth, Content Delivery Networks 
(CDNs) provide numerous benefits: reduced delivery cost for cacheable 
content, improved quality of experience for end users, and increased 
robustness of delivery. For these reasons, CDNs are frequently used 
for large-scale content delivery. As a result of the significant 
growth in content delivered over IP networks, existing CDN providers 
are scaling up their infrastructure and many NSPs and ESPs are 
deploying their own CDNs. Subject to the policy of the Content 
Service Provider (CSP), it is generally desirable that a given item 
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of content can be delivered to an end user regardless of that end 
user's location or attachment network. This creates a need for 
interconnecting (previously) standalone CDNs so they can interoperate 
and collectively behave as a single delivery infrastructure. The 
Content Distribution Network Interconnection (CDNI) working group has 
been chartered to develop an interoperable and scalable solution for 
such CDN interconnections. 


The CDNI Problem Statement [RFC6707] outlines the problem area that 
the CDNI working group is chartered to address. The Use Cases for 
CDNI document [RFC6770] discusses the use cases for CDN 
Interconnection. The Framework for CDN Interconnection [RFC7336] 
discusses the technology framework for the CDNI solution and 
interfaces. 


The goal of the present document is to document the requirements for 
the CDNI solution and interfaces. In order to meet the time lines 
defined in the working group charter, the present document 
categorizes the CDNI requirements as "High Priority", "Medium 
Priority", and "Low Priority". 


1.1. Terminology 


This document uses the terminology defined in [RFC6707]. In 
addition, the key words "High Priority", "Medium Priority", and "Low 
Priority" in this document are to be interpreted as follows: 


o "High Priority": When a requirement is tagged as "(HIGH)", it is 
considered by the working group as an essential function for CDNI 
and necessary to a deployable solution. This requirement has to 
be met even if it causes a delay in the delivery by the working 
group of a deployable solution. 


o "Medium Priority": When a requirement is tagged as "(MED)", it is 
considered by the working group as an important function for CDNI. 
This requirement has to be met, unless it is established that 
attempting to meet this requirement would cause a delay in the 
delivery by the working group of a deployable solution. 


o "Low Priority": When a requirement is tagged as "(LOW)", it is 
considered by the working group as a useful function for CDNI. 
The working group will attempt to meet this requirement as long as 
it does not prevent meeting the "High Priority" and "Medium 
Priority" requirements and does not cause a delay in the delivery 
by the working group of a deployable solution. 
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2. CDNI Model and CDNI Interfaces 


The "CDNI Expanded Model and CDNI Interfaces" figure and brief 
descriptions of the CDNI interfaces in [RFC7336] are replicated below 
for convenience. That document contains the definitive reference 
model and descriptions for the CDNI interfaces. 


o CDNI Control interface (CI): Operations to bootstrap and 
parameterize the other CDNI interfaces, as well as operations to 
pre-position, revalidate, and purge both metadata and content. 
The latter subset of operations is sometimes collectively called 
the "Trigger interface." 


o CDNI Request Routing interface: Operations to determine what CDN 
(and optionally what Surrogate within a CDN) is to serve an end 
user's requests. This interface is actually a logical bundling of 
two separate but related interfaces: 


* CDNI Footprint & Capabilities Advertisement interface (FCI): 
Asynchronous operations (as defined in [RFC7336]) to exchange 
routing information (e.g., the network footprint and 
capabilities served by a given CDN) that enables CDN selection 
for subsequent user requests; and 


* CDNI Request Routing Redirection interface (RI): Synchronous 
operations (as defined in [RFC7336]) to select a delivery CDN 
(Surrogate) for a given user request. 


o CDNI Metadata interface (MI): Operations to communicate metadata 
that governs how the content is delivered by interconnected CDNs. 
Examples of CDNI Metadata include geo-blocking directives, 
availability windows, access control mechanisms, and purge 
directives. It may include a combination of: 


* Asynchronous operations to exchange metadata that govern 
subsequent user requests for content; and 


* Synchronous operations that govern behavior for a given user 
request for content. 


o CDNI Logging interface (LI): Operations that allow interconnected 
CDNs to exchange relevant activity logs. It may include a 


combination of: 


* Real-time exchanges, suitable for runtime traffic monitoring; 
and 


* Offline exchanges, suitable for analytics and billing. 


Leung & Lee Informational [Page 4] 


RFC 7337 


CDNI Requirements 


August 2014 


/ N 
| csp | 
N / 
* 
* 
$ /\ 
* f°, 
-—--------2-------2----- | CDNI | -—--------2------------ 
/ Upstream CDN N | | / Downstream CDN \ 
| 4------------- * | oer | | +------------- + 
pF Control |« | | >| Control xe ex | 
| * Jer doda TOE | | | A MEE EEPE n * | 
| E db dp ee *| 
* 4------ *------ * | LI | +------ *------ + * 
* kk kk Logging |< > | Logging kk kc ko 
|[* * 0 o +-*----------- * | | | 4----------- *-+ >*=] 
| * * * * | | | | * * * * | 
eee * toe ------*-4 | | RI | | +-*---------*-4+...*.%.0, 
EM |« |-===] >| o] 
K : cd Req-Routing | be | | Req-Routing T : : 
< > 
[* * * +-—----------- +. | | | | +------------- + * * x] 
| * * x . | | | x x * | 
|* * * 4------------- + |. | MI | | +------------- OX * | 
[* * * | Distribution|< | | >| Distribution| * * *| 
x * * N / x * * 
* ke * p-—-------- + XN per + * k k 
|* * ***| +--------- +| | ..  Request...... +--------- + [eee * >| 
| * oo OIL | Surrogate | *eeeeceeeo* | SUrrogate |—t***** * | 
ee 4- +| | Acquisition | |*---------- foe | 
| $------------- + | | +------- *----- + | 
N / N * / 
— ———— Á(——— EE rc a a ae ae a a p a N a 
* 
* Delivery 
* 
ecd 
—— E hequesSt.ze£il€agee e gecxk4€£3*€ecrewe]| USer.|sziRBequest 
Agent 
4R------ * 
<==> interfaces inside the scope of CDNI 
**** and interfaces outside the scope of CDNI 
Figure 1: CDNI Expanded Model and CDNI Interfaces 
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Generic CDNI Requirements 


This section identifies generic requirements independent of the 
individual CDNI interfaces. Some of those are expected to affect 
multiple or all interfaces. Management is an important aspect of CDN 
operation. The fault and performance management is covered in CDNI 
Logging interface requirements. The other types of management are 
Specific to the CDN provider and not needed for interoperability 
between CDN providers. 


GEN-1 (MED) Wherever possible, the CDNI interfaces should reuse or 
leverage existing IETF protocols. 


GEN-2 (HIGH) The CDNI solution shall not require a change, or an 
upgrade, to the User Agent to benefit from content delivery 
through interconnected CDNs. 


GEN-3 (HIGH) The CDNI solution shall not require a change, or an 
upgrade, to the Content Service Provider delivering content 
through a single CDN, to benefit from content delivery 
through interconnected CDNs. 


GEN-4 (HIGH) The CDNI solution shall not depend on intra-CDN 
information to be exposed to other CDNs for effective and 
efficient delivery of the content. Examples of intra-CDN 
information include Surrogate topology, Surrogate status, 
cached content, etc. 


GEN-5 (HIGH) The CDNI solution shall support CDN interconnection 
when delivery to the User Agent is based on HTTP [RFC7230]. 
(Note that while delivery and acquisition "data plane" 
protocols are out of the CDNI solution scope, the CDNI 
Solution "control plane" protocols are expected to 
participate in enabling, selecting or facilitating operations 
of such acquisition and delivery protocols. Hence, it is 
useful to state requirements on the CDNI solution in terms of 
specifying which acquisition and delivery protocols are to be 
supported). 


GEN-6 (HIGH) The CDNI solution shall support acquisition across 
CDNs based on HTTP [RFC7230]. (The note above applies to 
this requirement, too.) 


GEN-7 (LOW) The CDNI solution may support delivery to the User 
Agent based on protocols other than HTTP. 


GEN-8 (LOW) The CDNI solution may support acquisition across CDNs 
based on protocols other than HTTP. 
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GEN-9 (MED) The CDNI solution should support cascaded CDN 
redirection (CDN1 redirects to CDN2 that redirects to CDN3) 
to an arbitrary number of levels beyond the first level. 


GEN-10 {MED} The CDNI solution should support an arbitrary topology 
of interconnected CDNs (i.e., the topology of interconnected 
CDNs cannot be restricted to a tree, ring, star, etc.). 


GEN-11 (HIGH) The CDNI solution shall prevent looping of any CDNI 
information exchange. 


GEN-12 {HIGH} When making use of third-party reference, the CDNI 
solution shall consider the potential issues associated with 
the use of various format of third-party references (e.g., 
NAT or IPv4/IPv6 translation potentially breaking third-party 
references based on an IP addresses such as URI containing 
IPv4 or IPv6 address literals, split DNS situations 
potentially breaking third-party references based on DNS 
FODNs) and wherever possible avoid, minimize or mitigate the 
associated risks based on the specifics of the environments 
where the reference is used (e.g., likely or unlikely 
presence of NAT in the path). In particular, this applies to 
Situations where the CDNI solution needs to construct and 
convey uniform resource identifiers for directing/redirecting 
a content request, as well as to situations where the CDNI 
solution needs to pass on a third-party reference (e.g., 
identify the IP address of a User Agent) in order to allow 
another entity to make a more informed decision (e.g., make a 
more informed request routing decision by attempting to 
derive location information from the third-party reference). 


GEN-13 (HIGH) The CDNI solution shall support HTTP Adaptive 
Streaming content. 


4. CDNI Control Interface Requirements 


The primary purpose of the CDNI Control interface (CI) is to initiate 
the interconnection across CDNs, bootstrap the other CDNI interfaces 
and trigger actions into the Downstream CDN by the Upstream CDN (such 
as delete object from caches or trigger pre-positioned content 
acquisition). The working group attempts to align requirements with 
the appropriate interface; however, solutions to these requirements 
may apply to a different interface or another interface in addition 
to the interface with which it is associated. 


Cir=1 {HIGH} The CDNI Control interface shall allow the Upstream CDN 


to request that the Downstream CDN, including cascaded 
Downstream CDNs, delete an object or set of objects and/or its 
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CDNI Metadata from the CDN Surrogates and any storage. Only 
the object(s) and CDNI Metadata that pertain to the requesting 
Upstream CDN are allowed to be purged. 


(MED) The CDNI Control interface should allow for multiple 
content items identified by a Content Collection ID to be 
purged using a single Content Purge action. 


(MED) The CDNI Control interface should allow the Upstream CDN 
to request that the Downstream CDN, including cascaded 
Downstream CDNs, mark an object or set of objects and/or its 
CDNI Metadata as "stale" and revalidate them before they are 
delivered again. 


{HIGH} The CDNI Control interface shall allow the Downstream 
CDN to report on the completion of these actions (by itself, 
and including cascaded Downstream CDNs), in a manner 
appropriate for the action (e.g., synchronously or 
asynchronously). The confirmation receipt should include a 
success or failure indication. The failure indication and the 
reason are included if the Downstream CDN cannot delete the 
content in its storage. 


(MED) The CDNI Control interface should support initiation and 
control by the Upstream CDN of pre-positioned CDNI Metadata 
acquisition by the Downstream CDN. 


(MED) The CDNI Control interface should support initiation and 
control by the Upstream CDN of pre-positioned content 
acquisition by the Downstream CDN. 


(LOW) The CDNI Control interface may allow a CDN to establish, 
update and terminate a CDN interconnection with another CDN 
whereby one CDN can act as a Downstream CDN for the other CDN 
(that acts as an Upstream CDN). 


(LOW) The CDNI Control interface may allow control of the CDNI 
interfaces between any two CDNs independently for each 
direction (e.g., for the direction where CDN1 is the Upstream 
CDN and CDN2 is the Downstream CDN, and for the direction 
where CDN2 is the Upstream CDN and CDN1 is the Downstream 
CDN). 
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(LOW) The CDNI Control interface may allow bootstrapping of 
the CDNI Request Routing interface. For example, this can 
potentially include: 


* negotiation of the request routing method (e.g., DNS versus 
HTTP, if more than one method is specified). 


* discovery of the CDNI Request Routing interface endpoints. 


* information necessary to establish secure communication 
between the CDNI Request Routing interface endpoints. 


(LOW) The CDNI Control interface may allow bootstrapping of 
the CDNI Metadata interface. This information could, for 
example, include: 


* discovery of the CDNI Metadata interface endpoints 


* information necessary to establish secure communication 
between the CDNI Metadata interface endpoints. 


(LOW) The CDNI Control interface may allow bootstrapping of 
the Content Acquisition interface. This could, for example, 
include exchange and negotiation of the Content Acquisition 
methods to be used across the CDNs (e.g., HTTP, HTTPS, FTP, 
ATIS C2 [ATIS-0800042]). 


(LOW) The CDNI Control interface may allow bootstrapping of 
the CDNI Logging interface. This information could, for 
example, include: 


* discovery of the CDNI Logging interface endpoints. 


* information necessary to establish secure communication 
between the CDNI Logging interface endpoints. 


* negotiation/definition of the log file format and set of 
fields to be exported through the logging protocol, with 
some granularity (e.g., on a per-content-type basis). 


* negotiation/definition of parameters related to transaction 
logs export (e.g., export protocol, file compression, 
export frequency, directory). 
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5. CDNI Request Routing Redirection Interface Requirements 


The main function of the CDNI Request Routing Redirection interface 
(RI) is to allow the Request Routing systems in interconnected CDNs 
to communicate to facilitate redirection of the request across CDNs. 


RI-1 (HIGH) The CDNI Request Routing Redirection interface shall 
support efficient request routing for small objects. This 
may, for example, call for a mode of operation (e.g., DNS- 
based request routing) where freshness and accuracy of CDN/ 
Surrogate selection can be traded off against reduced request 
routing load (e.g., Via lighter-weight queries and caching of 
request routing decisions). 


RI-2 (HIGH) The CDNI Request Routing Redirection interface shall 
support efficient request routing for large objects. This 
may, for example, call for a mode of operation (e.g., HTTP- 
based request routing) where freshness and accuracy of CDN/ 
Surrogate selection justifies a per-request decision and a 
per-request CDNI Request-Routing protocol call. 


RI-3 (HIGH) The CDNI Request Routing Redirection interface shall 
support recursive CDNI request routing. 

RI-4 (HIGH) The CDNI Request Routing Redirection interface shall 
support iterative CDNI request routing. 

RI-5 (MED) In case of detection of a request redirection loop, the 
CDNI Request Routing Redirection interface's loop prevention 


mechanism should allow redirection of the request on an 
alternate CDN path (as opposed to the request not being 
redirected at all). 


RI-6 (MED) The CDNI Request Routing Redirection interface should 
support a mechanism allowing enforcement of a limit on the 
number of successive CDN redirections for a given request. 


RI-7 (LOW) The CDNI Request Routing Redirection interface may 
support a mechanism allowing an Upstream CDN to avoid 
redirecting a request to a Downstream CDN if that is likely to 
result in the total redirection time exceeding some limit. 
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(HIGH) The CDNI Request Routing Redirection interface shall 
allow the Upstream CDN to include, in the query to the 
Downstream CDN, the necessary information to allow the 
Downstream CDN to process the redirection query. This could, 
for example, include: 


* information from which the geographic region pertaining to 
the IP address of the User Agent that originated the 
request can be inferred (e.g., User Agent FQDN in case of 
HTTP-based request routing, DNS Proxy FQDN in case of DNS- 
based request routing). 


* requested resource information (e.g., Resource URI in case 
of HTTP-based request routing, Resource hostname in case of 
DNS-based request routing). 


* additional available request information (e.g., request 
headers in case of HTTP-based request routing). 


(LOW) The CDNI Request Routing Redirection interface may also 
allow the Upstream CDN to convey information pointing to CDNI 
Metadata applicable (individually or through inheritance) to 
the requested content. For illustration, the CDNI Metadata 
pointed to could potentially include metadata that is 
applicable to any content, metadata that is applicable to a 
content collection (to which the requested content belongs) 
and/or metadata that is applicable individually to the 
requested content. 


(HIGH) The CDNI Request Routing Redirection interface shall 
allow the Downstream CDN to include the following information 
in the response to the Upstream CDN: 


* status code, in particular indicating acceptance or 
rejection of request (e.g., because the Downstream CDN is 
unwilling or unable to serve the request). In case of 
rejection, an error code is also to be provided, which 
allows the Upstream CDN to react appropriately (e.g., 
select another Downstream CDN, or serve the request 
itself). 


* redirection information (e.g., Resource URI in case of 
HTTP-based request routing, equivalent of a DNS record in 
case of DNS-based request routing). 


(HIGH) The CDNI Request Routing Redirection interface shall 
allow for per-chunk request routing of HTTP Adaptive Streaming 
content. 
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(LOW) The CDNI Request Routing Redirection interface may allow 
the Upstream CDN to use the information conveyed by the 
Downstream CDN during the Recursive Request Routing process to 
rewrite an HTTP Adaptive Streaming manifest file. 


(LOW) The CDNI Request Routing interface may allow the 
Upstream CDN to re-compute the message digest or digital 
signature over the invariant portion of the chunk URIs 
embedded in the HTTP Adaptive Streaming manifest file. 


(MED) The CDNI Request Routing Redirection interface should 
correlate the HTTP Adaptive Stream manifest file to the 
related chunks referenced in the manifest file. 


(MED) The CDNI Request Routing Redirection interface should 

allow for an efficient method of transferring request routing 
information for multiple chunks from the Downstream CDN to the 
Upstream CDN as part of the recursive request routing process. 


6. CDNI Footprint & Capabilities Advertisement Interface Requirements 


The main function of the CDNI Footprint & Capabilities Advertisement 
interface (FCI) is to allow the Downstream CDN to advertise the 
information regarding its footprint and capabilities to the Upstream 


CDN. 


FCI-1 


FCI-2 


(HIGH) The CDNI Footprint & Capabilities Advertisement 
interface shall allow the Downstream CDN to communicate to the 
Upstream CDN coarse information about the Downstream CDN 
ability and/or willingness to handle requests from the 
Upstream CDN. For example, this could potentially include a 
binary signal ("Downstream CDN ready/not-ready to take 
additional requests from Upstream CDN") to be used in case of 
excessive load or failure condition in the Downstream CDN. 


(MED) The CDNI Footprint & Capabilities Advertisement 
interface should allow the Downstream CDN to communicate to 
the Upstream CDN aggregate information to facilitate CDN 
selection during request routing, such as Downstream CDN 
capabilities, resources and affinities (i.e., preferences or 
cost). This information could, for example, include: 


* supported content types and delivery protocols 
* footprint (e.g., Layer 3 coverage). 


* a set of metrics/attributes (e.g., streaming bandwidth, 
storage resources, distribution and delivery priority). 
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* a set of affinities (e.g., preferences, indication of 
distribution/delivery fees). 


* information to facilitate request redirection (e.g., 
Reachability information of Downstream CDN Request Routing 


system). 
[Note: Some of this information -- such as supported content 
types and delivery protocols -- may also potentially be taken 


into account by the Distribution system in the Upstream CDN 
for pre-positioning of content and/or metadata in the 
Downstream CDN in case of pre-positioned content acquisition 
and/or pre-positioned CDNI Metadata acquisition.] 


(MED) In the case of cascaded redirection, the CDNI Footprint 
& Capabilities Advertisement interface should allow the 
Downstream CDN to also include in the information communicated 
to the Upstream CDN, information on the capabilities, 
resources and affinities of CDNs to which the Downstream CDN 
may (in turn) redirect requests received by the Upstream CDN. 
In that case, the CDNI Request Routing interface shall prevent 
looping of such information exchange. 


(LOW) The CDNI Footprint & Capabilities Advertisement 
interface may allow the Downstream CDN to communicate to the 
Upstream CDN aggregate information on CDNI administrative 
limits and policy. This information can be taken into account 
by the Upstream CDN Request Routing system in its CDN 
Selection decisions. This information could, for example, 
include: 


* maximum number of requests redirected by the Upstream CDN 
to be served simultaneously by the Downstream CDN. 


* maximum aggregate volume of content (e.g., in Terabytes) to 
be delivered by the Downstream CDN over a time period. 


(MED) The CDNI Footprint & Capabilities Advertisement 
interface should support advertisement of the following types 
of capabilities: 


* delivery protocol (e.g., HTTP versus Real Time Messaging 
Protocol [RTMP]). 


* acquisition protocol (for acquiring content from an 
Upstream CDN). 
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* redirection mode (e.g., DNS Redirection versus HTTP 
Redirection). 


* capabilities related to CDNI Logging (e.g., supported 
logging mechanisms). 


* capabilities related to CDNI Metadata (e.g., authorization 
algorithms or support for proprietary vendor metadata). 


FCI-6 (LOW) The CDNI Control interface may allow exchange and 
negotiation of delivery authorization mechanisms to be 
supported across the CDNs (e.g., URI-signature-based 
validation). 


FCI-7 (HIGH) The CDNI Footprint & Capabilities Advertisement 
interface shall support extensible fields used to convey the 
CDN capabilities and methods to indicate the footprint in the 
advertisement from the Downstream CDN to the Upstream CDN. 


7.  CDNI Metadata Interface Requirements 


The primary function of the CDNI Metadata interface (MI) is to allow 
the Distribution system in interconnected CDNs to communicate to 
ensure Content Distribution Metadata with inter-CDN scope can be 
exchanged across CDNs. We observe that while the CDNI Metadata 
Distribution protocol is currently discussed as a single "protocol", 
further analysis will determine whether the corresponding 
requirements are to be realized over a single interface and protocol, 
or over multiple interfaces and protocols. For example, a subset of 
the CDNI Metadata might be conveyed in-band along with the actual 
content acquisition across CDNs (e.g. content MD5 in HTTP header) 
while another subset might require an out-of-band interface and 
protocol (e.g., geo-blocking information). 


MI-1 (HIGH) The CDNI Metadata interface shall allow the Upstream 
CDN to provide the Downstream CDN with content distribution 
metadata of inter-CDN scope. 

MI-2 (HIGH) The CDNI Metadata interface shall support exchange of 


CDNI Metadata for both the dynamic content acquisition model 
and the pre-positioning content acquisition model. 


MI-3 (HIGH) The CDNI Metadata interface shall support a mode where 
no, or a subset of, the CDNI Metadata is initially 
communicated to the Downstream CDN along with information 
about how/where to acquire the rest of the CDNI Metadata 
(i.e., Dynamic CDNI Metadata acquisition). 
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(MED) The CDNI Metadata interface should support a mode where 
all the relevant CDNI Metadata is initially communicated to 
the Downstream CDN (i.e., pre-positioned CDNI Metadata 
acquisition). 


(HIGH) Whether in the pre-positioned content acquisition model 
or in the dynamic content acquisition model, the CDNI Metadata 
interface shall provide the necessary information to allow the 
Downstream CDN to acquire the content from an upstream source 

(e.g., acquisition protocol and Uniform Resource Identifier in 
Upstream CDN -- or rules to construct this URI). 


(HIGH) The CDNI Metadata shall allow signaling of one or more 
upstream sources, where each upstream source can be in the 
Upstream CDN, in another CDN, the CSP origin server or any 
arbitrary source designated by the Upstream CDN. Note that 
some upstream sources (e.g., the content origin server) may or 
may not be willing to serve the content to the Downstream CDN; 
if this policy is known to the Upstream CDN, then it may omit 
those sources when exchanging CDNI Metadata. 


(HIGH) The CDNI Metadata interface (possibly in conjunction 
with the CDNI Control interface) shall allow the Upstream CDN 
to request addition and modification of CDNI Metadata into the 
Downstream CDN. 


(HIGH) The CDNI Metadata interface (possibly in conjunction 
with the CDNI Control interface) shall allow removal of 
obsolete CDNI Metadata from the Downstream CDN (this could, 
for example, be achieved via an explicit removal request from 
the Upstream CDN or via expiration of a Time-To-Live (TTL) 
associated with the CDNI Metadata). 


(HIGH) The CDNI Metadata interface shall allow association of 
CDNI Metadata at the granularity of individual object. This 
is necessary to achieve fine-grain CDNI Metadata distribution 
at the level of an individual object when necessary. 


(HIGH) The CDNI Metadata interface shall allow association of 
CDNI Metadata at the granularity of an object set. This is 
necessary to achieve scalable distribution of metadata when a 
large number of objects share the same distribution policy. 


(HIGH) The CDNI Metadata interface shall support multiple 
levels of inheritance with precedence to more specific 
metadata. For example, the CDNI Metadata Distribution 
protocol may support metadata that is applicable to any 
content, metadata that is applicable to a content collection 
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and metadata that is applicable to an individual content where 
content level metadata overrides content collection metadata 
that overrides metadata for any content. 


(HIGH) The CDNI Metadata interface shall ensure that 
conflicting metadata with overlapping scope are prevented or 
deterministically handled. 


(HIGH) The CDNI Metadata interface shall allow signaling of 
content distribution control policies. For example, this 
could potentially include: 


* geo-blocking information (i.e., information defining 
geographical areas where the content is to be made 
available or blocked). 


* availability windows (i.e., information defining time 
windows during which the content is to be made available or 
blocked; expiration time may also be included to remove 
content). 


* delegation whitelist/blacklist (i.e., information defining 
through which Downstream CDNs the content may/may not be 
delivered) 


(HIGH) The CDNI Metadata interface shall be able to exchange a 
set of metadata elements with specified semantics (e.g., start 
of time window, end of time window). 


(HIGH) The CDNI Metadata interface shall allow exchange of 
opaque metadata element, whose semantic is not defined in CDNI 
but established by private CDN agreement. 


(HIGH) The CDNI Metadata interface shall allow signaling of 
authorization checks and validation that are to be performed 
by the Surrogate before delivery. For example, this could 
potentially include the need to validate information (e.g., 
Expiry time, Client IP address) required for access 
authorization. 


(MED) The CDNI Metadata interface should allow signaling of 
CDNI-relevant Surrogate cache behavior parameters. For 
example, this could potentially include: 


* control of whether the query string of HTTP URI is to be 
ignored by Surrogate cache. 
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* enforcement of caching directives by Downstream CDN that 
are different than the ones signaled in the HTTP headers 
(e.g., "Expires" field). 


* rate-pacing by Downstream CDN for content delivery (e.g., 
Progressive Download). 


(HIGH) The CDNI Metadata interface shall provide indication of 
related content (e.g., HTTP Adaptive Bit Rate chunks) by the 
Content Collection ID (CCID) metadata. This could be used by 
the Downstream CDN for operations on the group of content. 

For example, this could potentially include: 


* content acquisition for the entire set of files when one 
piece of content is requested. 


* local file management and storage bundles all the files for 
the content. 


* purging the entire set of files associated with the 
content. 


* logging of the delivery of the content for the session when 
at least one file in the set was delivered. 


(MED) The CDNI Metadata interface should support an optional 
mechanism allowing the Upstream CDN to indicate to the 
Downstream CDN which CDNI Log fields are to be provided for 
all content items, for specific sets of content items, or for 
specific content items delivered using HTTP. A CDNI 
implementation that does not support this optional CDNI 
Metadata Distribution interface mechanism shall ignore this 
log format indication and generate CDNI Logging format for 
HTTP Adaptive Streaming using the default set of CDNI Logging 
fields. (Note: This function may be part of the CDNI Metadata 
interface or the CDNI Control interface.) 


(MED) The CDNI Metadata interface should allow the Upstream 
CDN to signal to the Downstream CDN the Content Collection ID 
value for all, for specific sets of, or for specific content 
items delivered using HTTP. Whenever the Downstream CDN is 
instructed by the Upstream CDN to report the Content 
Collection ID field in the log records, the Downstream CDN is 
to use the value provided through the CDNI Metadata interface 
for the corresponding content. Note the Session ID field 
along with Content Collection ID may be used for HTTP Adaptive 
Streaming content. 
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(MED) The CDNI Metadata interface should allow the Upstream 
CDN to signal to the Downstream CDN the Authorization Group ID 
value for all the related HTTP Adaptive Streaming content 
(i.e., manifest file and chunks). The authorization result of 
a content (e.g., manifest file) is transferred over to related 
content (e.g., chunks). 


(HIGH) The CDNI Metadata interface shall support extensible 
format for CDNI Metadata delivery from the Upstream CDN to the 
Downstream CDN. 


8. CDNI Logging Interface Requirements 


This section identifies the requirements related to the CDNI Logging 
interface (LI). We observe that while the CDNI Logging interface is 
currently discussed as a single "protocol", further analysis will 
determine whether the corresponding requirements are to be realized 
over a single interface and protocol or over multiple interfaces and 
protocols. 


LI-1 


LI-2 


LI-3 


LI-4 


LI-5 


LI-6 


(HIGH) The CDNI Logging interface and architecture shall 
ensure reliable transfer of CDNI logging information across 
CDNs. 


(HIGH) The CDNI Logging interface shall provide logging of 
deliveries and incomplete deliveries to User Agents performed 
by the Downstream CDN as a result of request redirection by 
the Upstream CDN. 


(MED) In the case of cascaded CDNs, the CDNI Logging interface 
should allow the Downstream CDN to report to the Upstream CDN 
logging for deliveries and incomplete deliveries performed by 
the Downstream CDN itself as well as logging for deliveries 
and incomplete deliveries performed by cascaded CDNs on behalf 
of the Downstream CDN. 


(HIGH) The CDNI Logging interface shall support batch/offline 
exchange of logging records. 


(MED) The CDNI Logging interface should also support an 
additional mechanism taking into account the timing 
constraints for some types of logging records (e.g., near-real 
time for monitoring and analytics applications). 


(HIGH) The CDNI Logging interface shall define a log file 
format and a set of fields to be exported for various CDNI 
Logging events. 
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LI-7 (HIGH) The CDNI Logging interface shall define a transport 
mechanism to exchange CDNI Logging files. 


LI-8 (MED) The CDNI Logging interface should allow a CDN to query 
another CDN for relevant current logging records (e.g., for 
on-demand access to real-time logging information). 


LI-9 (LOW) The CDNI Logging interface may support aggregate/ 
summarized logs (e.g., total bytes delivered for a content 
regardless of individual User Agents to which it was 
delivered). 


LI-10 {LOW} The CDNI Logging interface may support logging of 
performance data for deliveries to User Agents performed by 
the Downstream CDN as a result of request redirection by the 
Upstream CDN. Performance data may include various traffic 
Statistics (the specific parameters are to be determined). 

The CDNI Logging interface may support the Upstream CDN to 
indicate the nature and contents of the performance data to be 
reported by the Downstream CDN. 


LI-11 {MED} The CDNI Logging interface should support logging of 
consumed resources (e.g., storage, bandwidth) to the Upstream 
CDN for deliveries where content is stored by the Downstream 
CDN for delivery to User Agents. The information logged may 
include the type of storage (e.g., Origin, Intermediate, Edge, 
Cache) as well as the amount of storage (e.g., total GB, GB 
used, per time period, per content domain) all of which may 
impact the cost of the services. 


LI-12 {MED} In the case of cascaded CDNs, the CDNI Logging interface 
should support the Downstream CDN to report consumed resources 
(e.g. storage, bandwidth) to the Upstream CDN where content 
is stored by the Downstream CDN itself as well as logging for 
storage resources when content storage is performed by 
cascaded CDNs on behalf of the Downstream CDN. 


LI-13 (HIGH) The CDNI Logging interface shall support logging of 
deleted objects from the Downstream CDN to the Upstream CDN as 
a result of explicit delete requests on via the CDNI Control 
interface from the Upstream CDN. 


LI-14 {HIGH} The CDNI Logging interface shall support the exchange 
of extensible log file formats to support proprietary 
information fields. These information fields shall be agreed 
upon ahead of time between the corresponding CDNs. 
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(HIGH) The CDNI Logging interface shall allow a CDN to notify 
another CDN about which CDNI Logging information is available 
for transfer and/or no longer available (e.g., it exceeded 
some logging retention period or some logging retention 
volume). 


(MED) The CDNI Logging interface should support the ability 
for the Downstream CDN to include the Content Collection ID 
and Session ID fields in CDNI log entries generated for HTTP 
Adaptive Streaming content. 


(MED) The CDNI Logging interface should provide privacy 
protection by not disclosing information that can be used to 
identify the user (e.g., method that anonymizes the IP address 
carried in the logging field). The use of the privacy 
protection mechanism is optional. 


9. CDNI Security Requirements 


This section identifies the requirements related to the CDNI 


security. Some of these are expected to affect multiple or all 
protocols. 
SEC-1 {HIGH} All the CDNI interface shall support secure operation 


SEC-2 


SEC-3 


SEC-4 


over unsecured IP connectivity (e.g., the Internet). This 
includes authentication, confidentiality, integrity protection 
as well as protection against spoofing and replay. 


(HIGH) The CDNI solution shall provide sufficient protection 
against denial-of-service attacks. This includes protection 
against spoofed delivery requests sent by User Agents directly 
to a Downstream CDN attempting to appear as if they had been 
redirected by a given Upstream CDN when they have not. 


(MED) The CDNI solution should be able to ensure that for any 
given request redirected to a Downstream CDN, the Downstream 
CDN can determine the Upstream CDN that redirected the request 
directly to the Downstream CDN (leading to that request being 
served by that CDN, or being further redirected). 


(MED) The CDNI solution should be able to ensure that for any 
given transaction log generated by the Downstream CDN and 
communicated to an Upstream CDN, the Upstream CDN can confirm 
the transmitted log record corresponds to a request 
redirection by the Upstream CDN. 
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SEC-5 (LOW) The CDNI solution may provide a mechanism allowing an 
Upstream CDN that has credentials to acquire content from the 
CSP origin server (or another CDN), to allow establishment of 
credentials authorizing the Downstream CDN to acquire the 
content from the CSP origin server (or the other CDN) (e.g., 
in case the content cannot be acquired from the Upstream CDN). 


10. Security Considerations 
This document discusses CDNI security requirements in Section 9. 
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